Stop the schema selector getting stuck in a pending state - #1194
Draft
malberts wants to merge 6 commits into
Draft
Stop the schema selector getting stuck in a pending state#1194malberts wants to merge 6 commits into
malberts wants to merge 6 commits into
Conversation
Fixes #980 Two fixes to the schema selector, used both when creating a subject from an existing schema and when choosing a relation's target schema. Typing a schema name out in full no longer selects it. The keystroke that completed the name used to commit the match, which in the subject creator jumped to the next step while the user was still typing. A schema is now selected only by clicking its entry or confirming it with the keyboard. The schema list now opens as soon as the field is focused. It used to stay closed until the user left the field and came back, because the field was focused before the schemas had finished loading. The field is a Codex Lookup rather than a Combobox, which reports typing and picking separately. Its expander chevron is gone as a result. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Mutation testing found two gaps. The focus test handed over its schemas before focus() could wait for them, so removing that wait still passed; it now delivers them only once focus() has been called, the way the network does. Nothing asserted that the committed schema is marked as the chosen entry in the list, so telling CdxLookup nothing about it went unnoticed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Picking the schema a relation already targets emitted `select` again, marking the schema editor dirty and putting an unsaved-changes prompt in the way of closing it after an interaction that changed nothing. Changing the committed schema now also clears the filter. CdxLookup resolves a selection against the menu as it stands, so a schema hidden by an active filter would have emptied the field. From the same review: the picker's tests browse from a focused field, because a CdxMenu only opens on focus and the assertions otherwise held against a list the user cannot see; menu entries are selected by role rather than by Codex class name; typing with surrounding whitespace, confirming a fully typed name with enter, and the subject creator focusing the picker are all covered now. `reconcileOnBlur` says what it does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Fixes:
Screencast_20260728_134410.webm |
Contributor
Author
|
Fixes:
Screencast_20260805_202351.webm |
malberts
marked this pull request as ready for review
August 5, 2026 20:06
The filter held the typed text trimmed and lower-cased, so a keystroke that left that form unchanged wrote the same string, the menu-items computed did not re-evaluate, and CdxLookup never saw the new array it waits for. It stays in the loading state it enters on every keystroke: the field keeps an animated striped background, which survives blur and refocus and clears only on a later keystroke that does reach the menu. The same missing update keeps the list from reopening from the field itself, so getting it back takes leaving the field and returning. A single space typed into an empty field reaches both symptoms, as does emptying the field after picking a schema, since picking already resets the filter. The filter now holds what the user typed, verbatim, and reduces it where it is applied. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Resetting the filter when the parent commits a schema had no test: removing it left every test passing, while the field went blank for a schema the active filter hides. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
malberts
force-pushed
the
pr-1174-review-fixes
branch
from
August 5, 2026 20:30
44316cc to
c6b6261
Compare
malberts
marked this pull request as draft
August 5, 2026 20:49
CdxLookup takes a change to its menu items as the answer to the user's keystroke, and marks the field as loading until one arrives. An edit that leaves the field's text as it found it, such as pasting a name over its own selection or a cancelled composition, wrote the same string, so no new list was produced and the field kept its loading animation until the next edit that did change something. Every edit now invalidates the menu, whatever the text does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
malberts
force-pushed
the
pr-1174-review-fixes
branch
from
August 5, 2026 20:55
c6b6261 to
ef57f0d
Compare
Base automatically changed from
fix/schema-picker-explicit-selection
to
master
August 13, 2026 22:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows-up to #1174
One regression that PR introduced by moving the selector from CdxCombobox to CdxLookup,
plus a test for a line it left uncovered. It targets that branch rather than master because
master has neither.
CdxLookup treats a change to its menu items as the answer to the user's keystroke, and
marks the field as loading until one arrives. Its own source says as much: the menu's
pending indicator is "meant to indicate that new menu items are being fetched or computed",
and the watcher that ends it reads a menu-items change as "in response to user input". The
picker was not always answering. Its filter held the typed text trimmed and lower-cased, so
any edit that left that form unchanged wrote the same string, the menu-items computed did
not re-evaluate, and CdxLookup went on waiting: a striped background on a field that is
loading nothing, surviving blur and refocus, clearing only on a later edit that did reach
the menu. The same silence keeps the list shut until you leave the field and return. A
single space typed into an empty field reaches it, as does emptying the field after picking
a schema, since picking already resets the filter. Every edit now invalidates the menu,
including one that leaves the text exactly as it found it: pasting a name over its own
selection, or a cancelled composition.
Separately, resetting the filter when the surrounding editor commits a schema had no test.
Removing that line left every test passing, while the field went blank for a schema the
active filter hides.
Reproduced in a browser against the dev wiki, on the subject creator and on a relation's
target schema, and confirmed absent from
master, where CdxCombobox has no loading stateat all and so carries no such contract.
Considered, omitted: a guard against Codex renaming
cdx-lookup--pending, which the twoloading-state tests name. A healthy field carries no modifier class, so an absence
assertion cannot tell a fixed field from a renamed class, and the only way to pin the name
is a test of Codex rather than of this component. Worth revisiting if the class moves.